The present invention relates in general to transaction processing, and more specifically, to methods, systems and computer program products for transaction processing in a distributed computing environment having both non-Java® based transaction processing products or modules (TPMs) and Java®-based TPMs.
Transaction processing or online transaction processing is a known computerized software approach to handling many varied types of common business or commercial (global) transactions, for example, a purchase of goods made online by an individual buyer using a credit card from a commercial seller of various goods. Transaction processing is typically carried out using a distributed computer or processor cluster, environment or system (e.g., a cloud, one or more stand-alone computers, etc.) in which various components or devices such as mainframe computers, memories, smartphones, etc., are located and are communicatively coupled together. Typically, the particular transaction must completely execute successfully. Otherwise, the transaction is considered to have failed and is then subject to roll back in which all of the operations of the transaction—including the successful ones—are erased and the transaction processing system is brought back to the state it was in prior to the start of the unsuccessful transaction.
It is common to have a global transaction span across multiple TPMs communicatively coupled together through software proprietary communication protocols. As per the known XA (“eXtended Architecture”) standard for distributed transaction processing (DTP), a TPM acts as a transaction coordinator and uses a two-phase commit process to ensure data consistency with the recoverable resources associated with the transaction. When there is more than one TPM involved in a logical unit of work (LUW) or operation as part of the distributed transaction processing process, the TPM that initiates the transaction assumes the responsibility of a coordinator and the remaining TPMs act as participants.
Modern, relatively large enterprise transaction processing computer or processor architectures or systems usually include both “traditional,” or older, pre-existing non-Java based TPMs (e.g., those based on the C, COBOL or other compiler-type software programming languages) as well as “newer” Java-based (e.g., Java Enterprise Edition (JEE)) or other interpreter-type software programming language (e.g., Python) TPMs. Thus, modern distributed TPMs are implemented using different software types. This is due to the different software programming language platforms utilized as well as the need to suit the services the TPMs provide. As such, the overall distributed transaction processing environment must operate across two distinct types of software programming language platforms or systems to maintain transaction context across those systems, to thereby successfully complete a global transaction.
Although newer, interpreter-type language-based TPMs can be communicatively coupled with older, more traditional compiler-type language-based TPMs, it is a challenge to extend transaction processing to an interpreter-type language-based TPM from a compiler-type language-based TPM which is already communicatively coupled with multiple other compiler-type language-based TPMs which utilize native proprietary protocols, and vice versa.